Field of the Invention
The description relates in particular to a device for controlling connected multimedia devices, in particular connected loudspeakers, also called wireless speakers.
It is increasingly common to connect a source device (computer, tablet, mobile phone, etc.) containing multimedia content to a wireless speaker suitable for reproducing the sound of the multimedia content. It seems desirable to be able to connect a source device to multiple wireless speakers in order to obtain better sound (for example stereophonic sound, or even 5.1 surround sound or other configurations). It is then desirable to synchronize these speakers so that there is no delay between the sound played on two different speakers. A similar problem arises in the case of multimedia content other than audio, for example in the case of video projection. This may involve the transmission of several copies of the same stream, for example live transmission of a video of a conference on several screens located in the same room. It may also involve the transmission on multiple screens of videos corresponding to the same scene from different points of view (for example in a video game context), the videos then being different but needing to be perfectly synchronized.
When all the connected loudspeakers used are from the same manufacturer and are known to the source device, the manufacturer can control the entire chain and can set up the synchronization software. Each speaker can for example communicate data such as a pointer indicating the next part of a buffer memory to be read or the state of a clock internal to the source device, which can be arranged to draw the necessary conclusions by determining the relative values of the various internal clocks and the different read positions in the respective buffer memories of the various speakers. However, when a source device connects to wireless speakers that it does not know and especially when these speakers are heterogeneous (for example from different manufacturers), it is impossible to synchronize these speakers as their operation and characteristics are unknown.
Description of the Related Art
A commonly used wireless protocol is the Bluetooth protocol. Bluetooth is a communication standard that is well known to the person skilled in the art, defined since 1994 and managed by a group of manufacturers (the Bluetooth SIG) which publishes the successive versions. The current version is version 4.2 and a version 5 has just been announced. Bluetooth allows two-way communication of data over short distances (known as a piconet which refers to a network covering a personal area). The range of Bluetooth devices is thus limited to a few tens of meters. Bluetooth uses radio waves that are in the UHF band (between 300 MHz and 3 GHz). Bluetooth aims to simplify connections between electronic devices by eliminating wired links. Bluetooth thus allows replacing, with wireless communications, the cords between a master multimedia device (hi-fi system, radio, computer, tablet, mobile phone, etc.) and target multimedia devices such as speakers arranged to reproduce a multimedia stream received.
Bluetooth speakers have met with some success because of their high portability.
However, if an audio data exchange profile called the A2DP profile is used, the Bluetooth standard does not allow a Bluetooth chip to transmit multiple audio streams in parallel to multiple multimedia devices that one wishes to synchronize. This A2DP profile does not allow synchronized point-to-multipoint transmission. The Bluetooth standard in fact states that: “The following restrictions are applied to this profile: 1. This profile does not support a synchronized point-to-multipoint distribution.” Thus, in theory it is not possible to design a device for synchronized control of Bluetooth multimedia devices with the synchronized control device comprising a single Bluetooth chip for controlling multiple multimedia devices, because Bluetooth does not allow it.
It has already been proposed to create a point-to-multipoint Bluetooth device for multiple speakers. For example, application FR2920930 filed on Sep. 6, 2007 and now permanently abandoned, proposed such a device. But this application did not describe how to implement such a device, which seems impossible under the Bluetooth standard if only one Bluetooth chip is used. The inadequate description of this application prevents drawing any relevant teachings as to how to create a point-to-multipoint link, and even more so a synchronized point-to-multipoint link.
Although Bluetooth does not provide for it, it would be possible to create in a Bluetooth chip a device to control several Source SEPs in order to control multiple Bluetooth devices (instead of providing as many Bluetooth chips in a control circuit as there are Bluetooth devices to be controlled). An SEP is a “Stream End Point”. Bluetooth communications are point-to-point between two SEPs. An SEP represents the resources and capabilities of a device. For example, a device such as a mobile phone may have three SEPs, one representing its capabilities as a video receiver, another representing its capabilities as an audio receiver with an SBC codec, and a last one representing its capabilities as an audio receiver with an aptX codec. Each codec must be associated with a different SEP than the one(s) associated with other codec(s), but the same codec can be associated with multiple SEPs.
However, if the Bluetooth devices are Bluetooth multimedia devices, the problem arises of synchronizing the signals transmitted to each of these Bluetooth multimedia devices in A2DP.
The acronym A2DP stands for “Advanced Audio Distribution Profile.” The conventional A2DP profile defines a set of protocols and procedures for the exchange of audio data via the Bluetooth protocol between a master device (known as the Source) and a slave device (known as the “Sink”, designating the ultimate destination of a stream, for example a Bluetooth speaker). This A2DP profile is constructed using several layers defined by the Bluetooth standard.
The profile relies in particular on low-level layers that are well known to those skilled in the art. These layers comprise:                a “Baseband” layer, the Baseband layer being identified by the reference BB in FIG. 1,        an “LMP” layer (acronym for “Link Manager Protocol”);        an “L2CAP” layer (acronym for “Logical Link Control and Adaptation Protocol”),        an SDP layer (“Service Discovery Protocol”).        
These layers are protocols defined in the Bluetooth standard.
The A2DP profile also relies on a high-level layer called the application layer (denoted AASo and AASi in FIG. 1, respectively for “Application Audio Source” and “Application Audio Sink”). This is the layer in which the device determines the transport parameters and the various services available. It is also at this level that the choice of codec used to transmit the audio data is made (which may involve decoding followed by re-encoding when the audio stream to be transmitted is already encoded, which is usually the case).
Lastly, the A2DP profile relies on an AVDTP layer (“Audio/Video Distribution Transport Protocol”) that defines the binary transactions between Bluetooth devices for setting up a stream and for streaming an audio and/or video stream using L2CAP. It therefore covers procedures for establishing the audio stream, negotiating the parameters of the audio stream, and transmitting the data of the audio stream. AVDTP comprises a signaling entity for negotiating streaming parameters and a transport entity for managing the stream itself. AVDTP defines a transport protocol for audio and/or video data. More specifically, AVDTP concerns the transport of audio and/or video data between two SEPs.
A limitation imposed by AVDTP according to the Bluetooth standard is that when a connection has been negotiated between two SEPs, these two SEPs must be locked to each other for streaming. By default, a connected SEP refuses any new connections. In recent Bluetooth products, a function known as “social mode” sometimes allows changing this default behavior. However, although this social mode function allows a new connection, it cuts off the current connection. For example, there can be two telephones connected to the same Bluetooth speaker, but multiple simultaneous transports cannot be set up. Switching to a new connection typically occurs by terminating the previous connection while keeping the previously connected telephone in memory. As a result, if there is only one audio source SEP on a Source device then only one AVDTP transport can be established to a given Sink device at a given time, according to the Bluetooth standard.
The L2CAP layer defines the most basic data exchange protocol of the Bluetooth specification. The L2CAP layer enables the segmentation and reassembly of packets, multiplexing, and quality of service. It is from this L2CAP layer that the various transport protocols (such as AVDTP) based on different Bluetooth profiles (such as A2DP) are implemented. An L2CAP channel is created between a CID (“Channel Identifier”) of a master device and a CID of a slave device, allowing the exchange of data between these two devices. The L2CAP channels are each configured to manage the control of data streams passing through channels defined by L2CAP (L2CAP channels). For this purpose, different parameters can be taken into account independently for each L2CAP channel, in particular:                An FTO or “Flush Timeout” parameter defines an expiration period for a data packet in a buffer memory of a master device. This period is infinite by default (blocked mode), which means that a transmitted packet that does not reach its destination is resent until a packet (the initial packet or the resent packets) has reached the destination. However, the period can also be such that retransmission never occurs (if the “Flush Timeout” parameter is set to an appropriate value defined by the Bluetooth standard), which amounts to a zero period. The period can also have a finite value. There exists a Boolean variable called “flag non-automatically flushable” in Bluetooth packets, which allows indicating that the packet concerned cannot be deleted automatically.        A QoS parameter (acronym for “Quality of Service”) which enables defining the maximum latency between inclusion of a packet to be transmitted in an L2CAP channel and its actual transmission.        Parameters called “Extended Flow Features”, replacing and supplementing the combination of the “Flush Timeout” and “QoS” parameters mentioned above.        
These parameters are negotiated between the Bluetooth stack of a master Bluetooth device and the Bluetooth stack of a slave Bluetooth device, and apart from the default values are not always supported.
L2CAP enables the implementation of different modes. These modes are also parameters of the L2CAP channels, in the same manner as the “Extended Flow features” parameters or the “Flush Timeout” parameter. It is the set of all these parameters (including modes) that enables modifying the control of streams. Each mode defines different procedures for managing data streams. Within the conventional Bluetooth framework (called BR/EDR), five operating modes are possible for an L2CAP channel. These modes are:                “Basic Mode” (basic L2CAP mode),        “Flow Control Mode”,        “Retransmission Mode”,        “Enhanced Retransmission Mode” (known as “ERTM”), and        “Streaming Mode” (known as “SM”).        
“Basic Mode” is the default mode and is supported by all Bluetooth stacks. It does not require any configuration. “Flow Control Mode” sends packets but never retransmits lost packets. However, these packets (called PDUs) are detected when they are lost, and “Flow Control Mode” allows the communication of a report listing the lost packets. “Flow Control Mode” and “Retransmission Mode” can only be used if “ERTM” and “SM” are not usable. These two modes (“Flow Control Mode” and “Retransmission Mode”) are now almost never used. “ERTM” makes it possible to take into account a given maximum number of retransmissions and a given maximum duration during which a retransmission can take place, and makes it possible to identify the packets that are lost or corrupted. “SM” is adapted for asynchronous data flows. It takes into account a finite “Flush Timeout” parameter. On the Bluetooth receiver side, if the buffer memory is full the previous data are overwritten.
In the Bluetooth standard, a parameter called “Retransmission and flow control option” allows choosing a mode. The Bluetooth standard recommends establishing “reliable” connections that limit data loss, using a “Basic Mode” with an infinite “Flush Timeout”, or in more recent Bluetooth stacks “ERTM” with any “Flush Timeout”.
In practice, no product on the market offers a synchronized point-to-multipoint A2DP control function for any Bluetooth multimedia devices.